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ABSTRACT 

Software  reuse  is  an  admirable  goal  that  has  many 
warts  in  application.  This  paper  discusses  one 
experience  in  reusing  a  large  suite  of  simulation  code 
in  a  significantly  different  environment.  Tank- 
Automotive  Research,  Development  and  Engineering 
Center  (TARDEC)  Vetronics  research  programs 
developed  over  several  years  a  significant  body  of 
vehicle  embedded  simulation  system  (ESS)  software. 
TARDEC  continues  to  evolve  this  ESS  to  meet  the 
simulation  needs  of  the  Future  Combat  Systems 
(FCS).  The  US  Army  Research  Development  and 
Engineering  Command’s  (RDECOM)  Simulation 
Technology  Center  (STC)  was  interested  in  reusing 
this  software  for  crewstations  being  considered  for  an 
embedded  training  and  mission  rehearsal  testbed.  This 
paper  discusses  the  STC  experience  in  reusing 
TARDEC’s  ESS  software.  The  paper  provides 
background  on  the  software  in  question  and  its 
intended  uses  by  both  organizations.  It  addresses 
some  of  the  issues  encountered  in  reuse,  such  as  the 
difficulty  in  understanding  the  volume  of  code  involved 
and  hardware  and  software  dependencies.  The  paper 
goes  on  to  discuss  the  tradeoffs  that  evolved  from 
these  issues  and  the  resulting  decisions  that  affected 
software  adaptation.  Finally,  the  paper  concludes  with 
a  discussion  of  plans  for  continued  adaptation  of  ESS 
software  for  STC  use  and  a  review  of  program 
successes. 

INTRODUCTION 

For  the  past  several  years  both  the  Vetronics 
Technology  Center,  US  Army  Tank-Automotive 
Research,  Development  and  Engineering  Center 
(TARDEC)  and  the  Simulation  Technology  Center 
(STC),  US  Army  Research  Development  and 


Engineering  Command  (RDECOM)  (formerly  the 
science  and  technology  element  of  the  US  Army 
Simulation,  Training  and  Instrumentation  Command 
(STRICOM)),  have  worked  to  create  simulation 
technology  that  could  be  embedded  into  close  combat 
vehicles.  TARDEC’s  interests  have  been  primarily  in 
vehicle  workload  issues,  while  STC  focused  on  using 
embedded  simulation  for  training  and  mission 
rehearsal.  The  two  organizations  have  shared  research 
ideas  and  products  through  several  years  of 
development.  With  the  advent  of  the  Future  Combat 
System,  both  programs  began  to  focus  their  research 
toward  this  developing  system  of  systems.  As  the 
direction  of  the  research  became  more  aligned,  other 
opportunities  to  share  technology  were  recognized  and 
pursued. 

BACKGROUND 

TARDEC 

For  FCS  the  Army  needs  smaller  and  lighter  combat 
vehicles  offering  increased  lethality,  survivability,  and 
mobility.  These  requirements  are  further  combined 
with  the  need  to  assimilate  and  distribute  more 
information  to,  from,  and  within  the  vehicle.  To  achieve 
these  goals,  the  Army'  s  future  combat  vehicles  will 
need  highly  integrated  multi-mission  capable 
crewstations.  The  Army'  s  move  toward  a  digital 
battlefield  has  also  created  a  tremendous  need  for 
revolutionary  increases  in  vehicle  and  command, 
control,  communications,  computers  and  intelligence 
(C4I)  systems  performance. 

To  achieve  some  of  these  goals  TARDEC  is  working 
on  the  Crew  integration  and  Automation  Testbed  (CAT) 
Advanced  Technology  Demonstration  (ATD)  to 
demonstrate  a  multi-mission  capable  two-man 
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crewstation  platform  concept.  These  concept 
crewstations  will  be  integrated  into  a  C-1 30- 
transportable  chassis  supporting  the  Army'  s  Objective 
Force  (OF).  This  program  focuses  on  an  improved 
soldier  machine  interface  (SMI)  design  using  indirect 
vision  driving  and  automated  decision  aids,  an 
advanced  electronic  architecture  design/network 
topology,  and  embedded  simulation.  By  demonstrating 
these  advanced  technologies  and  other  capabilities, 
the  CAT  ATD  will  prove  technology  readiness  to 
sufficiently  transition  and  integrate  hardware  and 
software  components  into  FCS. 

CAT  ATD  uses  embedding  simulation  technologies  to 
reduce  crew  workload  by  improving  training,  virtual 
battlespace  visualization  and  mission  rehearsal. 
Embedded  simulation  also  has  potential  for  virtual  test 
and  evaluation.  CAT  crewstations  have  been 
integrated  into  a  Light  Armored  Vehicle  (LAV)  Stryker 
variant  chassis.  The  CAT  ATD  has  supported  the 
Lead  Systems  Integrator  (LSI)  in  the  area  of 
Unmanned  Combat  Demonstration  (UCD). 

The  UCD  is  using  the  CAT  crewstations  to  control 
Armed  Robotics  Vehicles  (ARV)  reconnaissance 
variants.  The  CAT  and  Robotics  Follower  (RF)  ATD 
were  the  closest  surrogate  programs  available  to  the 
LSI  for  the  Control  Vehicle  (CV)/ARV  concept.  The 
UCD’s  main  function  is  to  prove  validity  of  the  CV/ARV 
for  Increment  1  of  FCS.  Workload,  robotics  maturity 
and  functional  ability  were  addressed  in  the  virtual 
environment  and  at  Ft.  Bliss  in  a  field  demonstration. 

Over  a  number  of  years,  TARDEC  research  evolved  a 
significant  body  of  vehicle  simulation  software  known 
as  an  Embedded  Simulation  System  (ESS).  Operating 
on  vehicle  crewstations,  this  software  simulates 
sensors,  weapons  and  robotic  vehicles  and  provides 
an  interface  for  the  soldier  to  interact  with  these 
simulated  systems.  Building  on  an  earlier  version  of  the 
ESS  known  as  Vetronics  Technology  Testbed  (VTT) 
the  CAT  ATD  ESS  configuration  operates  on  two 
crewstations  that  have  been  installed  in  a  LAV  vehicle 
to  produce  appropriate  crew  task  loading  for  mission 
scenarios  to  test  crewstation  design  and  demonstrate 
unmanned  combat. 

RDECOM 

In  parallel  with  the  TARDEC  work,  the  RDECOM  STC 
has  been  pursuing  a  research  program  targeting 
embedded  simulation  technology  specifically  for 
training  and  mission  rehearsal  applications.  The 
current  STC  effort,  Embedded  Combined  Arms  Team 
Training  and  Mission  Rehearsal  (ECATT/MR)  Science 
and  Technology  Objective  (STO),  is  researching 


embedded  simulation  technologies  for  training  and 
mission  rehearsal  for  FCS  platforms. 

Through  a  contract  with  the  Institute  for  Simulation  and 
Training  (1ST),  University  of  Central  Florida,  STC  built 
an  Embedded  Training/Mission  Rehearsal  (ET/MR) 
Testbed  to  integrate  and  demonstrate  various  STO 
technologies.  The  Testbed  consists  of  two,  low  cost, 
man-in-the-loop  crewstations  representing  crew 
positions  in  FCS  platforms.  The  ET/MR  Testbed 
crewstation  design  was  patterned  after  the  CAT  ATD 
crewstations,  albeit  with  much  less  capability  and  at 
much  lower  cost  as  they  did  not  require  the 
ruggedness  nor  the  fidelity  necessary  to  mount 
crewstations  in  an  actual  vehicle.  As  a  further  effort  to 
achieve  maximum  capability  with  minimum  cost, 
TARDEC  agreed  to  provide  RDECOM  with  the  ESS 
software  from  VTT  and  later  from  CAT  ATD  for  the 
ET/MR  Testbed. 

If  successful,  the  benefits  of  STC’s  reuse  of  the  VTT 
ESS  were  obvious.  TARDEC  has  invested  many 
person-years  of  development  into  the  ESS.  STC  could 
achieve  much  greater  simulation  functionality  with  its 
two-person  programming  staff  and  avoid  significant 
cost  if  the  ESS  would  satisfy  the  simulation  needs  of 
the  ET/MR  Testbed.  On  the  other  hand,  TARDEC 
would  also  benefit  from  this  reuse  as  STC  would 
provide  versions  of  ESS  software  back  to  TARDEC 
with  additional  debugging  and  added  functionality. 

VETRONICS  TECHNOLOGY  TESTBED  (VTT) 

Before  discussing  the  process  of  adapting  VTT  to 
Testbed  use,  some  understanding  of  the  various 
components  of  the  VTT  software  is  necessary.  The 
basic  architecture  consists  of  an  A-Kit  representing  the 
vehicle  and  interfaces  to  the  vehicle,  and  a  B-Kit 
consisting  of  the  Embedded  Simulation  System.  The 
major  components  of  the  ESS  are  depicted  in  Figure  1 
and  briefly  described  below. 

•  PIU  (Process  Interface  Unit)  -  The  sole 
communication  channel  between  simulation 
components.  It  allows  multiple  programs  to  interact 
asynchronously  in  the  overall  simulation.  PIU 
generally  hides  details  of  where  other  simulation 
processes  execute  and  inter-process  communication 
is  handled  implicitly.  All  VTT  processes  use  PIU. 

•  AKITInterface  -  The  peer  connection  to  the 
vehicle  or  A-Kit.  Provides  the  indirect  abstraction  for 
vehicle  resident  functions  and  controls.  Vehicle-side 
messages  of  interest  were  incorporated  into  the  host 
program. 


2 


SimControl  N  A-Kir/B-KIT  ICD 


Figure  1  ESS  Software  Components 


•  Command  and  Control  (C2)  -  Monitors  and 
responds  to  the  AKITInterface  for  incoming  Joint 
Variable  Message  Format  (JVMF)  radio  message 
traffic.  This  version  has  scripted  response  logic.  For 
example,  when  the  A-Kit  receives  a  JVMF  Overlay 
Message,  C2  can  respond  with  a  Free  Text  Message 
(“Roger  Over”).  A  number  of  JVMF  messages  were 
implemented,  including  Call  for  Fire  Report,  Logistics 
Report,  Obstacle  Report,  Situation  Report,  Spot 
Report,  Subsequent  Adjust,  and  Threat  Warning. 

•  World  -  The  link  between  the  image  generation 
visualization  software  and  the  PlU/simulation. 
Traditionally  a  single  host  process  is  used  to  drive  an 
image  generator,  however  the  VTT  architecture  uses 
many  individual  components  to  accomplish  the  host 
functionality. 

•  Sight/Weapons  -  Line  of  sight  weapons 
configuration  and  control.  Contains  logic  for  current 
weapon  orientation,  weapon  type  and  round  flyout. 

•  Network  Interface  Unit  (NIU)  -  The  link  between 
the  One  Semi-Automated  Forces  Testbed  (OTB)  and 
the  VTT  simulation.  It  uses  Distributed  Interactive 
Simulation  (DIS)  Version  2.04  to  relay  Protocol  Data 
Units  (PDUs)  to  and  from  OTB.  It  uses  the  OTB 
libraries  for  transformations  against  position, 
orientation  and  velocity. 

•  Mobility  -  Physics  model  used  to  navigate 
virtual  vehicles  across  terrain  databases. 


•  Vulnerability  -  Handles  incoming  round  casualty 
assessment.  Uses  a  geometry  model  and  OpenGVS 
software  for  damage  assessment. 

•  SimulationControlManagement  -  Uses 
configuration  files  to  locate  and  start/restart 
simulation  processes.  Scripts  are  executed  based  on 
the  state  of  the  simulation. 

ADAPTING  VTT  ESS  TO  TESTBED  USE 

The  VTT  ESS  software  is  functionally  robust  with  a 
code  base  estimated  at  approximately  140,000  lines  of 
code.  Since  the  ET/MR  Testbed  was  to  be  a  scaled 
down  version  of  TARDEC’s  testbed,  the  ET/MR 
Testbed  would  need  to  implement  only  a  portion  of  the 
simulation  functionality  built  into  the  VTT  code.  The  1ST 
Embedded  Team  also  had  limited  resources,  with  only 
one  full  time  software  engineer  and  one  part  time 
graduate  student  researcher,  so  the  possibility  of 
utilizing  the  entire  VTT  package  was  out  of  reach  in  the 
near  term.  The  team  followed  a  piecemeal  approach, 
prioritizing  desired  functionality,  and  then  focusing 
effort  on  the  priority  packages  until  the  simulation  was 
working  as  expected. 

In  March  2002,  TARDEC  provided  1ST  with  the  first 
drop  of  the  VTT  ESS.  This  drop  contained  a  scaled 
down  version  of  the  Process  Interface  Unit  (PI U)  with 
no  vehicle  functionality.  TARDEC  refers  to  this 
software  distribution  as  the  “PIUMinimal”  since  it  is  a 
minimal  selection  of  software  required  to  run  the  PIU 


3 


process.  The  PIUMinimal  is  an  ideal  tool  for  learning 
how  the  PIU  operates,  and  1ST  used  this  as  an 
opportunity  to  understand  and  exercise  the  system. 

The  second  software  installment  was  received  in  June 
2002  and  contained  most  of  the  core  VTT  source  code. 
Absent  from  the  distribution  were  vehicle  resident 
software  components  such  as  the  Map  Server  that 
provides  2-dimensional  (2D)  representation  of  terrain 
and  all  graphic  user  interfaces  (GUI)  used  in  the 
TARDEC  crewstations.  Since  1ST  has  neither  vehicle 
nor  an  appropriate  platform  in  which  to  run  vehicle- 
based  software,  1ST  had  to  “fill  in  the  gaps”  where 
vehicle  side  software  was  missing. 

The  first  tasks  with  the  new  drop  were  to  evaluate  the 
functionality  included  in  the  VTT  drop,  understand  the 
software  and  its  dependencies,  then  determine  what 
functionality  would  be  implemented  in  the  ET/MR 
Testbed.  Since  there  was  no  vehicle  in  which  the 
Testbed  version  of  VTT  controls  could  reside, 
TARDEC  provided  a  test  input  program  called  the 
“TestGUI”  that  simulated  vehicle  input  and  other  A-Kit 
(vehicle-side)  messages.  Unfortunately  the  TestGUI 
program  was  developed  on  an  SGI  platform  and  used 
a  licensed  widget  set  for  which  1ST  had  no  license.  A 
week  was  required  to  port  TestGUI  to  Linux  and  to 
convert  to  an  open  source  widget  set.  While  porting  the 
TestGUI  program,  the  VTT  software  was  updated  for  a 
newer  Linux  distribution  that  was  stable  on  ET/MR 
Testbed  hardware  (RedHat  Linux  7.3).  This  involved 
modification  to  some  library  and  API  calls  as  the 
original  VTT  operating  system  was  RedHat  6.2. 

After  several  weeks  of  studying  and  experimenting  with 
the  VTT  code,  implementation  of  ownship  mobility  was 
set  as  the  initial  functional  objective.  The  Mobility  and 
World  functions  were  identified  as  high  priority  for  this 
effort  and  work  was  initiated  that  successfully  installed 
these  components  on  the  ET/MR  Testbed. 

After  successfully  establishing  ownship  mobility,  the 
next  objective  involved  using  Mobility,  NIU, 
AKitlnterface  and  the  TestGUI  together  to  put  DIS 
packets  on  the  network.  Carmel  Applied  Technology 
Inc.’s  (CATI)  XIG  image  generator  was  used  to 
visualize  the  ownship  vehicle  and  understand  the 
cause-effect  relationship  between  A-kit  messages  on 
the  TestGUI  and  the  Mobility  behavior.  The  TestGUI 
program  proved  a  very  useful  tool  for  exploration  of  the 
A-Kit  messages,  and  lead  to  the  realization  that  vehicle 
simulation  beyond  the  TestGUI  would  be  required. 

1ST  developers  created  a  simulated  vehicle  program  to 
serve  as  a  logical  surrogate  for  the  actual  vehicle. 
Using  the  A-Kit  to  B-Kit  Interface  Control  Document 
(ICD)  that  describes  messages  between  vehicle  and 
ESS,  and  the  example  provided  by  the  TestGUI 


program,  1ST  implemented  the  necessary  protocol  to 
serve  as  the  behavioral  approximation  of  the  vehicle.  A 
control  yoke  and  pedals  were  implemented  as  an  off- 
the-shelf  solution  for  vehicle  control.  Additionally, 
incoming  B-Kit  vehicle  simulation  data  was  used  for 
graphical  display  of  vehicle  datum  such  as  a 
speedometer,  tachometer,  voltage  gauge,  and  Global 
Positioning  System  (GPS)  location.  Later  instantiations 
of  the  simulated  vehicle  included  gear  selectors, 
ordnance  selectors,  fuel  level  indicators  and  target  list 
displays.  Future  versions  of  the  simulated  vehicle  will 
include  an  object-oriented  ground  truth  state  vehicle 
class  for  flexibility  and  upgrade  purposes. 

The  next  phase  in  adapting  VTT  software  was  to 
optimize  the  World  component  so  that  the  host 
processes  directly  controlled  the  image  generator, 
rather  than  it  being  controlled  indirectly  with  DIS 
packets.  Direct  host  control  of  image  generators 
increased  frames-per-second  performance  by  60%  and 
decreased  display  latency. 

In  working  with  the  World  component  it  was  discovered 
that  many  World  functions  were  disabled  by  the  default 
system  state,  which  is  controlled  by  the  Simulation 
Management  component.  Since  there  were  no 
immediate  plans  for  using  the  Simulation  Management 
component  a  good  deal  of  time  was  spent  disabling  the 
Simulation  Management  specific  code.  This  same 
situation  was  encountered  when  integrating  the  line  of 
sight  (LOS)  package  that  controls  the  turret  motion, 
line  of  sight  weapons,  and  targeting  functions.  Again 
Simulation  Management  specific  code  had  to  be 
disabled  for  the  system  to  respond  correctly. 

After  successfully  adapting  the  World  component,  the 
ET/MR  Testbed  had  a  basic  embedded  simulation 
system  that  could  move  ownship,  employ  weapons  and 
sighting  systems,  and  destroy  DIS  generated  entities. 
The  Testbed  and  ESS  were  used  for  demonstrations  of 
STO  research  at  the  Interservice/Industry  Training, 
Simulation  and  Education  Conference  (l/ITSEC)  in 
December  2002,  and  again  for  demonstrations  of 
embedded  training  technology  in  the  House  and 
Senate  Office  Buildings  in  Washington,  DC  in  February 
2003. 

For  a  variety  of  reasons,  some  original  VTT  distribution 
components  were  left  out  of  the  ET/MR  Testbed 
configuration.  For  example,  the  Vulnerability 
component  that  detects  when  the  ownship  has  been 
damaged  or  killed  required  a  license  for  OpenGVS  that 
the  STC  program  neither  owned  nor  desired  to 
purchase.  C2  and  SimulationControlManagement 
components  were  not  implemented  due  to  time  and 
labor  considerations.  As  program  requirements 
change,  these  components  may  be  added  to  the 
Testbed  ESS. 
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EXTENSION  OF  VTT  SOFTWARE 

In  addition  to  adapting  the  VTT  ESS  to  Testbed  use, 
1ST  also  added  functionality  to  the  ESS. 

AUDIO  COMPONENT 

The  ET/MR  Testbed  required  an  audio  system.  Initial 
specifications  called  for  a  simple  set  of  sounds  that 
would  be  played  in  direct  response  to  input  events. 
During  the  research  phase  it  appeared  feasible  to 
implement  spatial  renderings  of  most  vehicle  related 
sounds  and  ambient  entity  noise.  Most  data  required 
for  a  reasonably  accurate  sound  component  already 
existed  in  VTT,  and  all  positional  data  provided  by  the 
Mobility  and  NIU  components  was  spatial  in  nature. 
The  VTT  PIU  component  already  had  some  initial  high- 
level  work  toward  a  sound  system  that  provided  a 
baseline  for  development.  A  very  useful  audio  library 
called  OpenAL  was  located  that  is  OpenGL  compliant 
and  provides  tools  to  render  spatialized  audio  in  a  way 
that  is  independent  of  the  coordinate  system  unit, 
rendering  sound  effects  correctly  regardless  of  whether 
the  coordinate  system  is  measured  in  feet  or  meters. 

One  of  the  issues  in  implementing  spatial  audio 
software  is  tracking  with  respect  to  the  listener  the 
location  and  orientation  of  the  sound  generating 
entities  involved  in  the  simulation.  The  new  audio 
component  added  an  entity  class  and  container  for 
tracking  entity  location.  Another  issue  concerned 
rendering  sound  from  too  many  entities  simultaneously 
because  the  audio  card  can  handle  only  a  limited 
number  of  simultaneous  sounds.  An  algorithm  was 


developed  to  determine  which  entities  would  be 
rendered  at  a  given  instant.  Ownship  sounds  are  given 
priority  and  are  always  rendered.  Entities  are  given 
priorities  such  that  the  closer  the  entity  (if  the  entity  is 
not  dead)  the  higher  the  priority.  If  there  are  50  entities 
within  a  specific  distance,  then  the  n  closest  entities 
(that  are  still  alive)  are  chosen  to  render,  where  n  is  the 
maximum  number  of  audio  samples  the  card  can 
handle  minus  the  number  of  samples  reserved  for  the 
ownship.  A  class  hierarchy  of  sound  sources  was 
developed  to  handle  different  styles  of  the  audio 
elements  such  as  instantaneous  (cannon  firing),  or 
continuous  (an  engine  running).  The  Close  Combat 
Tactical  Trainer  (CCTT)  sound  library  was  imported 
and  used  without  resampling.  This  sound  system 
component  was  provided  back  to  TARDEC. 

UNMANNED  VEHICLE  STATUS  (UVSTATUS) 

One  of  the  objectives  of  the  ET/MR  Testbed  is  to 
experiment  with  training  for  robotics  management. 
However,  the  VTT  software  did  not  have  a  robotic 
control  component.  This  component  was  being  added 
for  the  CAT  ATD  but  for  CAT  it  would  be  closely 
coupled  with  vehicle  software  and  therefore  not  useful 
to  the  ET/MR  Testbed.  To  functionally  create  this 
capability,  1ST  developed  a  scaled  down  version  of  the 
GUI  that  TARDEC  was  developing  as  the  CAT  soldier 
machine  interface  (SMI).  1ST  considered  it  important  to 
remain  generally  consistent  with  the  GUI  being 
developed  by  TARDEC.  Graphics  and  layouts  of  CAT 
SMI  specifications  were  adapted  to  Testbed  use  in 
order  to  maintain  the  look  and  feel  of  CAT  GUI  as 
shown  in  Figure  2. 


Figure  2:  Screen  Shot  of  UVStatus  Application 
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The  UVStatus  component  functionality  was  limited  for 
the  Testbed.  It  serves  primarily  as  a  current  status 
display  for  unmanned  vehicles  (UVs)  controlled  by  the 
ownship.  Features  were  developed  to  allow 
visualization  of  sensor  imagery  from  remote  air  and 
ground  robotic  vehicles  and  to  quickly  switch  between 
views  of  the  deployed  assets.  Four  levels  of  zoom  and 
IR  features  were  implemented  in  the  UVStatus 
application.  A  robotic  vehicle  control  interface  was  also 
added  and  is  addressed  in  Future  Plans.  A  different 
robotic  vehicle  instrument  panel  was  also  designed 
and  implemented. 

The  UVStatus  application  required  a  completely  new 
integration  with  the  PIU  since  no  previous  component 
could  be  leveraged.  PIU  integration  requires  a  number 
of  modifications  to  support  new  processes  consisting  of 
approximately  1 1  different  steps  as  documented  in  the 
PlUComm  maintenance  guide.  Additionally,  new 
message  types  for  UV  viewpoint  manipulation  were 
added,  involving  modifying  the  ICD  and  at  least  16 
discrete  modifications  to  the  PIU  core  software  per 
message.  These  modifications  are  reasonably  well 
documented  in  the  PlUComm  maintenance  guide. 
Every  major  change  to  the  PIU  required  a  recompile  of 
all  the  other  PIU  based  components  in  order  to  link 
with  the  latest  PIU  behavior. 

TRADE-OFFS 

Earlier  paragraphs  addressed  a  number  of  tradeoffs 
made  during  the  course  of  this  effort.  This  included  the 
tradeoffs  between  labor  vs.  the  number  of  services  that 
could  be  implemented  and  the  cost  of  license  vs.  loss 
of  functionality.  Other  tradeoff  decisions  also  affected 
to  final  version  of  the  ET/MR  capability. 

VEHICLE  VS.  NO-VEHICLE  -  MAP  SERVER 

Both  VTT  and  CAT  ESS  were  developed  with  the 
objective  of  operating  from  crewstations  in  live 
vehicles.  Their  design  leveraged  vehicle  systems  and 
vehicle  operating  systems,  using  vehicle  components 
where  possible  rather  than  duplicating  that  capability  in 
VTT  and  CAT  development.  As  a  result  some  of  the 
software  that  supports  the  VTT  and  CAT  ESS  is 
vehicle-based  and  uses  the  vehicle’s  VXWorks 
operating  system.  A  key  issue  for  RDECOM  and  1ST 
concerned  how  to  handle  vehicle-related  software 
dependencies. 

One  of  IST’s  major  vehicle-related  decisions 
concerned  the  2D  map  provided  to  crewstation 
operators.  TARDEC  uses  the  VXWORKS-based  Map 
Server  to  present  this  2D  map  and  also  as  a  touch 
screen  input  device  to  direct  robotic  vehicle  movement 
and  other  actions.  1ST  elected  to  use  OneSAF  Testbed 
(OTB)  Plan  View  Display  for  presentation  of  the  2D 


situational  awareness  information  as  acquiring 
VXWORKS  for  the  Map  Server  was  not  an  option.  By 
using  OTB,  the  ET/MR  Testbed  gave  up  some 
desirable  Map  Server  features  such  as  map 
symbology.  On  the  other  hand,  using  OTB  avoids 
having  to  support  an  additional  terrain  database  format 
for  the  Map  Server  and  offers  easily  magnified 
visualization  of  2D  terrain.  This  was  considered  a 
reasonable  tradeoff  as  emerging  versions  of  OTB  may 
accommodate  the  desired  symbology  and  other 
applications  as  discussed  later  would  provide  the 
interface  to  robotic  vehicles. 

SOLDIER  MACHINE  INTERFACE 

The  GUI  supporting  soldier-machine  interface  in  VTT  is 
also  a  vehicle  resident  software  system.  This  required 
that  1ST  develop  a  separate  SMI  for  the  Testbed  based 
on  an  ESS-resident  GUI.  The  resulting  ET/MR  Testbed 
SMI  generally  followed  the  CAT  SMI  design,  again 
striving  to  remain  consistent  with  CAT.  The  ET/MR 
Testbed  SMI  deviates  somewhat  from  CAT  in  that  this 
SMI  supports  only  the  functions  needed  for  the 
Testbed.  As  more  of  the  CAT  software  functionality  is 
added,  the  SMI  will  expand  accordingly. 

FUTURE  PLANS 

STC  and  1ST  continue  to  pursue  integration  of  other 
CAT  software  functionality,  such  as  new  models  for 
vehicle  and  weapons,  and  the  Reconnaissance 
Surveillance  and  Target  Acquisition  (RSTA) 
component.  With  TARDEC,  STC  is  also  pursuing  a 
joint  demonstration  of  embedded  training  and  mission 
rehearsal  using  ECATT/MR  STO  research  products 
and  the  CAT  vehicle  in  late  FY04. 

Using  products  from  an  STC  robotics  STO, 
modifications  are  being  made  to  the  ESS  to  support 
Testbed  control  of  both  live  and  virtual  robotic  vehicles. 
In  lieu  of  the  CAT  robotic  control  component  that  is 
closely  coupled  with  vehicle  systems,  efforts  are 
underway  to  integrate  the  Robotics  Multi-Functional 
Operators  Control  Unit  (OCU).  Developed  by 
RDECOM  and  Unit  of  Action  Maneuver  Battle  Lab 
(UAMBL)  under  STC’s  Advanced  Robotic  Simulation 
STO,  OCU  integration  will  expand  the  PIU  process  and 
add  various  robotic  control  features  to  the  SMI. 
Because  of  differences  between  OCU  and  CAT  robotic 
control  architectures,  this  function  will  not  be  useful  to 
TARDEC. 

Another  of  the  ECATT/MR  STO  contractors,  Stottler 
Henke  Associates,  Inc.  (SHAI),  is  developing  a 
prototype  Intelligent  Tutor  oriented  to  training  robotic 
management  at  the  operator  level.  Their  effort  will 
utilize  the  robotics  OCU  in  the  ET/MR  Testbed  as  the 
baseline  system  for  tutor  research.  1ST  is  working  with 
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SHAI  to  expand  the  PIU  to  accommodate  the  data 
demands  of  their  Intelligent  Tutor  processes.  TARDEC 
has  expressed  interest  in  using  the  high  level  features 
of  this  tutor  with  the  CAT  ESS  and  the  intelligent  tutor 
will  be  included  as  part  of  a  software  deliverable  to 
TARDEC. 

In  another  STO  effort,  United  Defense  Limited  Partners 
(UDLP)  Ground  Systems  Division  is  researching 
embedded  training  for  situational  awareness  between 
the  FCS  Infantry  Carrier  Vehicle  (ICV)  and  its 
dismounted  infantry.  1ST  will  create  an  ICV  version  of  a 
Testbed  crewstation  and  modify  the  current  ESS 
software  as  necessary  to  represent  FCS  ICV 
functionality.  UDLP’s  situational  awareness  research 
products  will  be  integrated  into  the  Testbed  for 
research,  evaluation,  and  demonstration.  TARDEC 
has  also  expressed  interest  in  this  component  and  it 
will  be  included  as  part  of  a  software  deliverable  to 
TARDEC. 

Still  a  third  STO  contractor,  Science  Applications 
International  Corporation  (SAIC)  is  researching  the  use 
of  Force  XXI  Battle  Command  Brigade  and  Below 
(FBCB2)  as  a  control  station  for  OTB.  This  work  will 
also  be  integrated  into  the  Testbed  and  provided  to 
TARDEC.  SAIC  is  also  researching  single  host 
architectures  for  FCS  embedded  training.  If  successful, 
this  architecture  may  replace  the  current  ET/MR 
Testbed  architecture. 

CONCLUSIONS 

An  embedded  simulation  system  built  from  VTT  ESS 
as  described  above  is  now  functional  and  is  running  in 
the  crewstations  of  the  RDECOM  FCS  ET/MR 
Testbed.  So  in  answer  to  the  title  question,  no,  reusing 
vehicle  simulation  software  is  not  “mission  impossible”. 
Nor  is  it  an  easy  task.  Adapting  any  software  package 
to  a  different  use,  especially  a  package  as  large  and 
complex  as  VTT,  is  a  meticulous,  time-consuming, 
labor-intensive  task.  But  when  the  new  purpose  is  as 
closely  matched  to  the  original  purpose,  as  was  the 
case  here,  it  is  also  a  very  effective  use  of  resources. 
Had  RDECOM  been  required  to  develop  the  ET/MR 
Testbed  embedded  simulation  system  from  scratch, 
available  resources  would  have  been  woefully 
inadequate  to  develop  the  level  of  functionality  that 
exists  today  based  on  VTT. 
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